Information systems relate to complementary networks of hardware and software. In such systems, resources comprised in one network, for example data resources, are shared with other adjacent networks, where the resources are utilised in subsequent actions. Often, prior to the execution of any subsequent action, a decision action is carried out to identify available resources, which are to form the basis for any subsequent actions. In order to ensure correct and error free operation of such systems, it is necessary that the decision action is taken on the basis of the correct and most recent state of a resource, which varies in time. Typically, the state of the resource is defined and updated manually. This ensures that available resources are known to the system, and that the decision action is carried out on the current resource state. Manual updating of resource states may be suitable in small and relatively simple information systems, where resource states are not subject to significant fluctuations over short periods of time and the number of different adjacent networks sharing the resources is minimal. Manual updating is less suitable in larger systems, or in systems where resource states may be subject to significant fluctuations over short periods of time, as this places a significant burden on a human operator and leads to bottlenecks forming at the updating process, which leads to delays in the accurate recording of a resource's state. Also, as the number of different adjacent networks increases the likelihood that the resource state will change in a short period of time is increased. As a result of these delays often the actual state of a resource becomes disassociated from the recorded state of the resource, which in turn can have detrimental knock-on effects on any subsequent decision action executed on the basis of inaccurate out-of-date resource status data.
One way the above problem is mitigated in the prior art is to limit the potential for changes of state of the resource, by assigning and making resources available only for use in specific actions. Once assigned for use in a specific action, the resource may no longer be available by other networks for different actions. This significantly reduces the sources of resource status fluctuations. However, this solution is undesirable in that it significantly limits the flexibility of the information system and its utility to a large system with many adjacent networks, and results in stagnant resources. In other words, once a resource has been allocated for use in a specific action it cannot be used for other actions, even when the resource isn't subsequently used for the allocated action, in which case the resource stagnates. For example, a decision action may identify and make a resource available for use in a subsequent action on the basis of resource status. If the resource is not subsequently used for the allocated action, then the resource remains unused and stagnates. This lack of flexibility disadvantageously results in an inefficient use of available system resources and also reduces the concurrency of the system by reducing shared resources.
The above described shortcomings of prior art information systems may be considered with reference to a real world example, with reference to FIG. 1. It is to be appreciated that the problem and its subsequent solution are not limited to the field of the example described below (namely, the financial industry), which is only provided for illustrative purposes.
FIG. 1 is a schematic illustration of an information system 1 used in the financial industry, and specifically of the type used in an electronic tri-party collateralisation system, arranged to carry out tri-party repurchase (repo) transactions. In such examples, the resources relate to financial assets, such as properties, securities, bonds etc. By way of background, in an electronic repo transaction (i.e. a repo transaction implemented using an information system), assets held by a first party using a first terminal 3, are used as collateral to securitise a loan from a second party using a second terminal 5. In such transactions the first party is traditionally referred to as a collateral giver (CG), and the second party is traditionally referred to as a collateral receiver (CR). Typically, the repo transaction has a finite time duration mutually agreed between the CG and the CR, and comprises an agreed start date and an agreed end date. Within the agreed time duration, and at the latest by the agreed end date, the CG must repay the loan amount in addition to any agreed interest. Once the loan amount has been repaid, the collateralized assets are returned by the CR to the CG—this step is commonly referred to as a reverse repo transaction. The terms of the repo transaction are agreed by the first and second parties prior to carrying out the repo transaction. The terms of the repo transaction typically define the start date and the end date of the transaction, the amount of the loan, any applicable interest, and the characteristics of assets that the second party (the CR) is willing to accept as collateral, in addition to the characteristics of assets that the first party (the CG) is willing to offer as collateral. The characteristics of qualifying assets may relate, for example to any one of the following non-limiting characteristics: asset type (e.g. bond, government bond, security etc.), asset issuer rating, underlying currency, country of origin, whether the asset is part of an index, and liquidity.
The CG's assets are often held in multiple different asset depositories 7, 9, 11, 13. Each depository may relate to a different bank, securities holding company, and/or any other entity that maintains assets. The different asset depositories 7, 9, 11, 13 may be located in different geographical territories. Each depository 7, 9, 11, 13 comprises a server 15, 17, 19, 21 and an operatively connected asset database 23, 25, 27, 29. The asset database 23, 25, 27, 29 comprises a database of all the assets associated with a particular user held by the specific depository.
In order to execute an electronic collateralisation transaction, during an initial enrolment process the CG, from the first terminal 3, nominates the assets that the CG is willing to make available for use in a subsequent repo transaction. The nominated assets are subsequently transferred from the relevant asset depositories 7, 9, 11, 13 to a transaction agent 31, via a shared communication network 33, which may relate to a wide area network such as the internet, a private network, or any other communication network.
The transaction agent system 31 (the agent) comprises an asset depository 34 operatively connected to a server 35, and to a collateralisation search engine 37. The nominated assets are stored in the asset depository 34, and define a pool of assets that the CG has made available for use in repo transactions. The CG, and the CR both provide their collateralisation requirements to the collateralisation search engine 37. For example, the CG defines the characteristics of assets that the CG is willing to offer for use as collateral in the transaction with the CR, and forwards the asset characteristics from the first terminal 3 to the collateralisation search engine 37.
Similarly, the CR defines the characteristics of assets that the CR is willing to accept as collateral for a loan, and forwards the characteristics to the collateralisation search engine 37 from the second terminal 5. Both sets of asset characteristics are received by the collateralisation search engine 37, and are used to generate an aggregated search query, which satisfies both the CR's and the CG's provided asset characteristics. For illustrative purposes consider an example where the CG selects the following asset characteristics:                Asset Type: Stock        Minimum Credit Rating (S&P/Fitch Rating): CCC        Maximum Credit Rating (S&P/Fitch Rating): AA        Minimum number of different stocks required: 3        
Similarly, the CR also defines the minimum characteristics that must be satisfied by the assets that the CR is willing to accept as collateral:                Asset Type: Bonds, Stock        Minimum Credit Rating (S&P/Fitch Rating): A+        Maximum Credit Rating (S&P/Fitch Rating): No maximum        
Upon receiving both the CG's and CR's collateralisation requirements, the collateralisation search engine reviews the provided asset characteristics and generates an aggregated search query that satisfied both the CG's and the CR's provided asset characteristics. In this example, the CG's provided collateralisation requirements indicate that the CG is only willing to offer stocks as collateral, that have a minimum of a CCC credit rating and a maximum of AA credit rating. Furthermore, the CG has indicated that a minimum of three different stocks must be selected for use as collateral. Similarly, the CR has indicated that they are willing to accept bonds and/or stocks as collateral for the loan, that have a minimum of an A+ credit rating. The CR has not indicated any maximum credit rating that must be satisfied.
On the basis of the provided asset characteristics, the collateralisation search engine 37 generates an aggregated query which satisfies both the CR's and CG's provided collateralisation requirements. In this instance, the aggregated query will require the following asset characteristics be satisfied:                Asset Type: Stock        Minimum Credit Rating (S&P/Fitch Rating): A+        Maximum Credit Rating (S&P/Fitch Rating): AA        Minimum number of different stocks required: 3        
The collateralisation search engine 37 subsequently executes the aggregated search query on the asset depository 34. Assets comprised in the asset depository 34 that satisfy the aggregated search query, and thus by extension also satisfy the terms of the agreed repo transaction, qualify to be selected by the collateralisation search engine 37 for use as collateral. A subset of the qualifying assets is selected which have a requisite value matching that required for the collateralisation. Only assets comprised in the agent's asset depository 34 are queried by the collateralisation search engine 37, for compliance with the aggregated search query and hence for compliance with the repo transaction criteria. Whilst assets are held in the agent's asset depository 34 they cannot be used in other unrelated actions. This inevitably leads to an inefficient use of assets, since many assets, including those assets that do not satisfy the aggregated search criteria and assets that satisfy the aggregated search criteria (qualifying assets) but which are not selected, will remain inactive in the agent's asset depository 34. In other words, once assets have been transferred to the agent's asset depository 34 the can only be used for subsequent tri-party repo transactions managed by the agent 31—they cannot be used in other unrelated actions.
One way of mitigating for this shortcoming is to maintain a mirrored asset database (not shown) in place of the asset depository 34. The mirrored asset database maintains a record of the assets and their associated statuses that the CG has nominated for use in subsequent repo transactions. As the status of an asset changes, this information is relayed to the agent 31 by the relevant asset depository 7, 9, 11, 13, such that the mirrored asset database may be updated accordingly. Additionally, since in this case the assets aren't physically held by the agent 31, they can be used in alternative actions when they are not selected for use as collateral in a subsequent repo transaction. However, a shortcoming of this solution is that the asset status held by the agent must be maintained in real time, to ensure that the collateralisation search engine 37 selects assets for use as collateral on the basis of up-to-date status information. Asset status information is time dependent and can fluctuate significantly over a period of time, in particular when the asset is available for use in alternative actions. To ensure that asset status information is up-to-date at the agent's mirrored asset database, asset status data messages are forwarded to the agent 31 from the relevant asset depository 7, 9, 11, 13. In practice, this means that the agent 31 is often inundated with very large numbers of status update data messages for processing. Often, the volume of received status updates is so large that it is not possible for the agent's server 35 to process each received status message in real time. Instead, status messages are queued in a memory buffer (not shown) for subsequent processing once server processing resources become available. As a result, it is common for a discontinuity to arise between the actual asset status as held by the relevant asset depository 7, 9, 11, 13, and the recorded asset status held by the agent 31 in the mirrored asset database. This can have knock-on effects for the collateralisation search engine 37 and the accuracy of the aggregated search results, due to assets being selected for use as collateral on the basis of erroneous status data. For example, if a particular asset is selected for use as collateral by the collateralisation search engine 37 on the basis of erroneous asset status data, then it will come to light during settlement (i.e. when the assets are physically transferred to the CR in accordance with the terms of the repo transaction), and may lead to the terms of the repo transaction remaining unfulfilled—for example, where the sum of the values of the provided assets are insufficient to collateralise the loan, or where an asset has been selected for use as collateral whose actual characteristics no longer satisfy the aggregated search criteria. Similarly, if the asset has been used for another action, and the agent's mirrored asset database has not been appropriately updated, there is a risk that this asset could be selected by the collateralisation search engine 37. During settlement it would quickly become clear that the asset is no longer available, and would ultimately result in the CG not fulfilling their part of the agreed repo transaction. The above problems tend to arise where the state of an asset varies over a short period of time, and the mirrored asset database is not updated frequently enough to reflect the asset status in real time.
A further shortcoming of the prior art information systems, and specifically prior art collateralisation systems, is the time and resources required of the collateralisation search engine 37 to carry out the collateralisation search—in other words, the time and resources required to search the mirrored asset database or the agent's asset depository 34, as the case may be depending on the specific implementation in the prior art.
For illustrative purposes only, where each asset comprises at the very least ten different characteristics, and each one of the CG and CR define a threshold value for each one of the ten different asset characteristics that must be satisfied in order for the asset in question to be used as collateral, and the database or the asset depository 34 comprises 1000 different assets, then the collateralisation search engine 37 must search a total of 10,000 different characteristics in order to determine which assets satisfy a single aggregated search query. This search is repeated for each different aggregated search query. These values are for illustrative purposes only, as in practice each asset may comprises significantly more characteristics, and each user may comprise on the order of thousands or hundreds of thousands of different assets. Accordingly, the number of characteristics that are searched for each different aggregated search query is staggeringly large. Furthermore, the collateralisation search engine 37 is configured to carry out aggregated searches for thousands if not hundreds of thousands of different repo transactions per day. This means that the processing overheads required of the collateralisation search engine are extremely high.
One way in which the above problem is mitigated for is by restricting the number of different collateralisation searches afforded to each user per unit of time. For example, each user may be restricted to a single aggregated search per day (i.e. one repo transaction per day). This solution is unduly limiting, since it significantly limits the utility of existing electronic collateralisation systems.
It is an object of the present invention to at the very least address some of the above described shortcomings of existing prior art information systems, and in particular to address the shortcomings of information systems used in the financial industry. However, it is to be appreciated that the solutions provided by the present invention may be implemented in any information system, and are not restricted for use in the financial industry.